(1) Field of the Invention
The invention relates to input/output (I/O) in a mainframe computer system. More specifically, the invention relates to virtualizing I/O in a mainframe computer system.
(2) Background
A typical mainframe may have up to ten central processing units (CPUs). An operating system (O/S), such as OS390, MVS ESA, VM or VSE, available from International Business Machines (IBM), typically executes on the mainframe and provides an interface between the hardware and higher level software. The O/S traditionally defines six classes of interrupts: program check (PC), supervisor call, I/O, machine check, external and restart. PC interrupts are generally bad, signifying that code is bad and usually results in failure. Conversely, some interrupts occur routinely, such as an I/O interrupt to indicate completion of an I/O transaction. Each CPU has associated therewith a prefix save area (PSA) that contains pointers to the interrupt service routines for handling each of these interrupt classes. Some software designers have employed this feature to reroute interrupt service requests by supplying a different address such that when an interrupt of that class occurs, the O/S routes the request to a custom interrupt handler. For example, one vendor rerouted the PC interrupt branch point to log information relating to system failure.
A typical mainframe conducts a very large amount of I/O. To facilitate this, up to 256 I/O channels may exist. Each I/O channel is identified by a channel path identifier (CHPID). Each CHPID may be coupled to a control unit which is a computer that may be connected to multiple I/O devices of a single type. For example, a single control unit might be connected to a plurality of direct access storage devices (DASD) or a plurality of tape drives. This leads to geometric growth of I/O devices to which the mainframe might be connected. Additionally, some prior art systems also permit daisy chaining of control units so that any particular CHPID may, via the daisy chain, reach an arbitrarily large number of control units. Other techniques, such as ESCON introduce a switch between the CHPID and a plurality of control units. These techniques exacerbate the proliferation of the number of possible devices connected to a mainframe. A further complication of I/O in the mainframe environment is that multiple mainframes are able to share one or more control units. Thus, in addition to having an I/O system that is extraordinarily scalable, the I/O system must also facilitate sharing between multiple mainframes.
Tape as a storage medium for mainframes is extremely important. The tape is used for archival purposes and commonly as a primary storage medium. Often, tape is used even for short term storage where the file size from day to day varies significantly such that it is difficult to effectively allocate DASD space for the file. Vast and expensive tape management subsystems have been developed which prevent tapes once written from being overwritten until otherwise authorized.
Commonly, tape cartridges are available in 400 MB, 800 MB, and more recently, 10 GB and 20 GB sizes. The tape capacity is expected to continue to increase. Unfortunately, a typical application seeking access to a tape in which to store its data set is not likely to fill up an entire tape. Thus, if, for example, the data set is 100 MB, the tape size is 400 MB, the application will gain access to the tape, store its data set, close the tape, and the tape will remain underutilized for the period that that data must be archived. This has resulted in significant under-utilization of tape cartridges such that, on average, cartridges may be only 25% utilized. While it is, of course, possible in a mainframe environment to put multiple data sets having different formats on a tape, it is not generally done because it requires an agreement between the potential users to allocate the tape capacity. As the number of applications seeking access to the tape increases, the management overhead becomes prohibitive.
This problem led to the development of a software stacking product to try to improve capacity utilization. Generally, after a plurality of applications have placed their data on a plurality of different tapes, the software stacking products load the tapes and move data from one tape to another. This uses mainframes resources and also creates the potential problem that the application may remember where it stored the data, e.g. the particular cartridge number, resulting in recovery errors. Moreover, if a single application wants two data sets simultaneously stacked on the same tape, failure may result. Also, even if two applications are searching data sets from the same tape, one must wait until the first completes its access. This may significantly negatively impact the main frames ability to do batch processing. As a result of these logistical and overhead problems, the software stacking products have largely failed to satisfy the capacity issues existing in the industry.
Typical tape systems are leased because turnover in technology makes purchasing them economically impractical. One problem with existing hardware tape drives is that they require a large amount of physical space and tend to be quite expensive. For example, if a user wants 64 drives (to permit up to 64 applications to simultaneously write to tape), significant amounts of physical area must be allocated to those drives. In addition to the floor space, the lease for such systems usually includes a maintenance charge on a per drive basis, including a drive automation, that may be on the order of $1000 per month. Thus, in the 64 drive example, $64,000 a month is spent purely in maintenance charges for the physical drives. The underutilization problem further increases costs as a large number of cartridges are required to hold less data.
More recently, vendors, such as IBM and Storage Technology, Inc., have come out with hardware virtual tape systems. The IBM system employs an RS 6000 to look like a control unit. The RS 6000 is associated with a DASD and six tape drives. Thus, when an application sends data to the virtual tapes, the RS 6000 loads the data set into the DASD and then migrates it to the tape later. The system permits emulation of 64 tape drives with only six physical drives, and thus, 64 applications may believe they are writing simultaneously to tape even though only six physical drives exist. While this solution does save significant floor space, it still involves significant hardware investment costs and maintenance costs. Additionally, it has limited scalability because for each unit, you must incur an additional hardware cost. Finally, the IBM solution uses a proprietary storage format which is not generally readable by other storage tape drives. Thus, for those users that wish to share data over long distances, the IBM solution may not be suitable.
A method and system of emulating an input/output (I/O) device in a mainframe environment is disclosed. A started task executing as part of the operating system gains control of I/O instructions directed to virtual devices by insuring that such I/O instructions cause interrupts. The started task then hooks the branch point for such interrupts. Upon obtaining control, the started task causes the I/O source to believe a transaction with a predefined data space in a general storage area on board the mainframe is actually a transaction with a physical device.